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1. INTRODUCTION 

Congestion control is a process to regulate the sending rate of the source on the network so the 
sender may adjust the entry of data according to the network condition to ensure sender's Quality of Service 
(QoS) requirements are fulfilled [1]. A good congestion control will ensure that there is no drop in quality 
and assure a good quality network [2], [3]. It is widely known that an end-to-end packet loss control such as 
Transmission Control Protocol (TCP) has several inefficiencies [4]. One reason of inefficiency is that TCP 
treats packet loss as congestion signal. Therefore, it cannot distinguish between packet loss due to congestion 
with packet loss due to other causes. 

Packet loss as a congestion signal implies that action can only be done after congestion occurs [5]. 
TCP uses assumption that the network does not provide explicit feedback to the source [6], which makes 
each source to estimate the nature of the network path, such as round trip time (RTT) or usable bandwidth, to 
deliver efficient end-to-end congestion. To improve TCP performance, previous research introduced the use 
of explicit congestion signals to the network [7]. This method is commonly called the Router Assisted 
Congestion Control (RACC). In the traditional Internet, RACC method is applied to each router where the 
router provides feedback to the end system about the state of the network and tells the sender to send packets 
at a specific rate. Figure | gives a simple overview of routers that always provide feedback information to the 
end-user. RACC is modeled using the M/G/1-PS queue theory to calculate the aggregate rate on each router 
(node). The aggregated rate at each node / follows a simple model as described by the following equation [8]: 


R, = C, (1 - pi) (1) 
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where R; is the sending rate for a link, C; is the link capacity, and p, is the link utilization. 

There are three solutions offered for RACC in the traditional Internet. The first solution is to use a 
router to detect congestion and send this information to the end system. Based on this information, the end 
system decides to control the congestion on the network. The example of this category is Explicit Congestion 
Notification (ECN) [9] and Quick-Start [10]. The sending rates in both protocols are decided at the end 
system based on information received from the network and the characteristics of each application. The 
second solution is to use a router to detect congestion and available network resources, and at the same time, 
the router distributes network resources for each information flow. The example of this category is Explicit 
Congestion Control Protocol (XCP) [11], and Rate Control Protocol (RCP) [12]. In this second approach, the 
end system only accepts recommendations from the router to adjust its sending rate. This approach allows the 
router to decide the sending rate for each flow without causing congestion on the network. 


Provide feedback 


Figure 1. Router assisted congestion control 


To calculate the change in flow sending rate, XCP calculates the aggregate bandwidth for each 
router. XCP uses the following equation to calculate the desired adjustment of the aggregate bandwidth [11]. 


R(t) = aC -() -8 TP Q) 


In this equation, Cis the capacity of the outgoing link, y(t) is the rate of its outgoing traffic, q)(t) is 
the persistent queue during the previous control interval and d is the average RTT. The resulted aggregate 
feedback R,(t) can be positive or negative and is distributed among the traversing flows. The fairness 
controller uses the Additive-Increase/Multiplicative-Decrease (AIMD) principle to allocate the positive or 
negative feedback. Positive feedback is distributed equally among all flows and negative feedback is 
distributed proportionally to their current throughput. XCP has two disadvantages: first, the startup flow is 
working slowly, so the completion time of flow is not smooth for small flow [13]. Second, it requires per- 
packet calculation; this raises the problem of significant overhead [12]. 

RCP was developed by Nandita [12] with the aim of providing a simpler congestion control 
mechanism. RCP assumes that the sender uses a rate-based delivery mechanism. Equal to XCP, RCP requires 
calculating the aggregate rate to adjust the flow sending rate. RCP calculates the aggregate rate R,(t) once per 
interval control with the following equation: 


a(C, — y(t)) -£ E 


(3) 


R(t) = R(t — d) [ + 7 


Where R;(t) is the common feedback rate, d is the average RTT and C; is the capacity of the outgoing link. 
y,(t) is the aggregate outgoing traffic which was measured during the last control interval, q(t) is the current 
queue occupation d is the update interval duration with d. It can be shown that RCP is locally stable if certain 
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conditions for a and £ are fulfilled [12]. Despite these improvements, XCP and RCP still face many 
challenges especially in queue support. The problem of the queue support in this system is that the protocol 
assumes only a single queue, contrary to the design of a high-end router that rarely has only one queue. The 
implementation can be tricky if there are thousands of flows passing through the routers with different 
characteristics. 

Finally, the third solution is to use a router to detect congestion along the path and provide 
information to the end system. The example of this category is the Open Box Protocol (OBP) [14]. OBP uses 
a collaboration router to identify network resources along the path and deliver this information to the end 
system. The end system made the congestion control decision using the data received from the router. The 
following equation shows how the sending rate is adjusted. In OBP, The initial sending rate W(to) depends on 
the available bandwidth AB(to), the capacity CB(to) at the narrow link and the constants a and f [14]. 


W (to) = a * AB (to) + P * CB(t) (4) 


Every time a new ACK packet is received, the feedback information inside the packet is used to 
make adjustments in transmission rate. OBP claims that its computation is simpler than XCP and ROP. 
However, the sender on OBP should create decision of adjusting the sending rate using only the information 
on the router along the path. This information is still a local category because the recipient does not 
understand the actual network conditions. Consequently, the OBP should always be careful in increasing and 
decreasing the delivery rate to maintain the network stability. 

In general, RACC can improve network performance. However, the RACC method is run by using a 
distributed framework as in traditional networks has some drawbacks. It requires a router (s) that supports 
signaling bandwidth of the set of parameters of the sending rate [15]. The presence of incomplete information 
about network conditions makes the issue of efficiency and stability. The congestion control scheme with 
network support becomes inefficient so that a global information provider mechanism is needed that can be 
used by congestion control mechanisms to control network congestion. Congestion control using global 
information has been proposed by Monia et al. [16] proposed OpenTCP, a TCP adjustment dynamics 
framework based on SDN. The sending rate adjustment in OpenTCP is global-based information managed by 
the controller. OpenTCP has filled the SDN application gaps in the congestion control field. However, 
OpenTCP is a new architecture and needs several modifications on some elements of the network such as 
having to modify the source, forwarding nodes and controllers. OpenTCP also has no specific target rate and 
adjustment methods. Lingyun et al. [17] present multiple active queue management algorithms. The 
algorithm is executed according to the location of the congestion on the network. This algorithm is adaptive 
to link condition. 

The link condition is detected by monitoring the statistical center, if there is a congestion link, then 
the information flow on this link is transferred by the OpenFlow controller. This method claims to be 
effective for congestion control. Nevertheless, this algorithm does not fully take into account the condition of 
network globally. Yao [18] proposed an algorithm called Software-Defined Congestion Control (SDCC). 
This approach has the characteristics of centralized control and can get a global topology for integrated 
network management. SDCC can optimize link utilization to control network congestion. However, SDCC 
still only considers network performance and does not pay attention to flow performance. Congestion control 
using SDN approach is still in early development stage. The proposed works have not discussed the 
weaknesses, and performances improvements of router assisted control in traditional networks. The most 
extensive work for the field of congestion control in the SDN is proposed for the data center as in [19]-[21]. 

In this paper, we proposed a new Router Assisted Congestion Control (RACC) mechanism that we 
call Path Associativity Centralized Explicit Congestion Control (PACEC). PACEC works on the SDN 
framework to overcome the weaknesses of the RACC in traditional Internet by providing global network 
information. We use comprehensive information to improve the accuracy of feedback to determine the source 
sending rate. By using SDN technology, congestion control utilizes the global knowledge of the network in 
its decision making. Data monitoring collects network information, and this information is used by the 
controller to make centralized decisions in response to changing network conditions [22]. This approach 
produces accurate information so that the sender's sending rate can be customized appropriately according to 
network conditions. 

PACEC calculates the rate by involving all the nodes along the connection path through which the 
information flows. Therefore, the sending rate of the information flow does not need to change as long as it 
still passes through the same path and the update timer of the controller has not ended. PACEC can also set 
the source sending rate starting at high-speed so that network resources can be used more efficiently. This 
proposed mechanism is the novelty of this research in the congestion control domain. The rest of this paper is 
structured as follows: section 2 explains the related works within the topic of the RACC. Section 3 describes 
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the design of the proposed mechanism in this paper. Section 4 describes the simulation results of the 
proposed mechanism, and finally, Section 5 describes the conclusions and possible future research directions. 


2. PROPOSED METHOD 

This section provides an overview of the PACEC draft [23]. To better understand the motivations 
behind PACEC, let us remember that RACC uses the basic equations we have written in Equation (1) to 
determine the aggregate rate on a link. From that equation we can see that information of available bandwidth 
covers only within local. Consequently, an RACC router will need to coordinate with other routers when 
implemented into networks with multiple routers. To avoid this drawback, PACEC implements a centralized 
congestion control mechanism, while the RACC router on the traditional Internet calculates the aggregate 
rate for a link only. PACEC can calculate the aggregate rate for a path, where the path has been provided to 
distribute the flow from the source to the destination. With this mechanism, the flow is guaranteed by route 
and rate when the flow is allowed to enter into the network. Our proposed method is described in the 
following sections. 


2.1. Path Rate (Rp) 

Similar to the case of the RACC routers, PACEC requires calculation on aggregate rates to adjust 
the sending rate. The difference is that the RACC calculates an aggregate rate for one link only. PACEC 
calculates the aggregate rate for a path. We call aggregate rate on PACEC as path rate (Rp). To get the path 
rate, we consider a network model whose topology is characterized in Figure 2. The network model is a path 
consisting of several links (J, 2,..., H). The whole link is connected to a centralized controller. End system as 
the source of information flow is connected to the ingress switch as the gateway to the network. In this case, 
nodes C;serves as ingress switch. The source f; has an associated sending rate of 7;. Flow is transmitted from 
source to destination via a path that has capacity Cp. 


Controller: 
Congestion control policy 


Information of R, 


New control action 


Source fj 


\ J Destination 


Figure 2. Network model of PACEC 


A path containing a series of H link(s) will have the path rate (R,) formulated by the following equation: 


Rp = min G. Q- Ji) (5) 


T;is the i_th average link utilization of collected by controller i, where [; = so yiis the i_th average traffic 
i 


link, g; is the i_th queue link, C; is thei_th link capacity. In contrast to RACC in the traditional Internet, 
PACEC uses J;, which is a utilization matrix whose elements are global information network. Information 
about T; is obtained by the controller globally from each switch incorporated in the controlled network. The 
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main advantage of I; is that it can be a precise solution for Rp, which is not under-estimated nor over- 
estimated. Sub-section 3.2 describes how PACEC obtains such information. 


2.2. Rp Updating 

Network conditions vary from time to time. Therefore the controller needs to update the network 
information continuously to deliver an effective policy. The controller updates the information of R, in each 
update period T, and the controller will provide updated information to the ingress switch. R, is affected by 
the switch utilization 7;. R, changes if there is a change in J;. In this section, we describe how the controller 
obtains the updated information on J;. Suppose there are H switches that send the updated information to the 
controller in constant time interval At. Thus, each delivery of data is done atTs = (At, 2At, 3At, ... .... kAt), 
where T, is time update switch. The controller processes the information for the controller at a period T, 
with T, = m.T, so that every time the update is performed, the controller collects information m times with 
interval 7;. If the total observation time is T and during this time interval there are k times where information 


; ; k : : ; 
is collected, then the controller requires an update of m Umes that are done at time interval index 


Sp S2 e Sk_ p Sk, where m ÍS total information at observation time T as shown in Figure 3. Here s, denotes 
m m 
the index of time interval where a controller collects information from each switch. 


Tc = m.Ts 
E | 
Ts 
m 
k=l k=2 k=m+]1 k=m+3 ints k=s.m 
j=0 j=2  j=s4 j=m j=m+2 j=m+4 j=m+4 
Š s2 Skim 
e~ ~ T —— p 
Figure 3. Information update 
Link utilization in each time index se for each link i can be calculated as 
m 
TOE D Yijr(s-tym F Mijres-m) a 
mL 4 Ci 
J= 


Where y;j represents the packet passing through a switch ¿at time index j (t = j. Ats), whereas qij 
represents the queue length at switch i at j (t = j. At). The y; and q; are collected every time interval Ts to 
k.Ts. The y;p is the traffic on node / from time interval to p, where p=1,2, ....... k. Furthermore, R, for every 
update period s can be written as 


R,(s) = min C;.(1- Sis) (7) 


or 
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m 
CERTI 1 OY: j(s-1)m + qi js-1)m) 1 
S Eh Goat a Cj m (8) 
j=l 


Available bandwidth on each link as proposed in Equation (8) differs from traditional available 
bandwidth model given in Equation (1). In this mechanism, we continuously update the available bandwidth 
based on actual utilization and queue length at every node in the path as given in Equation (5). Traditional 
routing, on the other hand, only relies on a specific node as given in Equation (1). 


2.3. Sending Rate Update 

Sending rate update aims to adjust the source sending rate (r;) based on current network conditions. 
As mentioned before, the source sending rate adjustment on PACEC is based on the path rate (R,,) calculated 
by the SDN controller. Every Tc period, the controller updates R,. Then in each of these periods, the source 
gets a new rate corresponding to R,, which is informed by the controller to the source through the ingress 
switch. The new rate is independent of the previous rate. If there is N flow to be transmitted on a path and 
each flow is given the same rate, then R, on each controller update is divided equally. The following equation 
shows how the sending rate (ri) is adjusted. 


P Piece Tee am) 
min c;.{1—- ( 2 e 
i=1.H ' ( Xj=1 ci (9) 


max (s) N 


ri 


Equation (9) denotes the maximum sending rate that can be provided to transmit a flow so that the source 
sending rate r; meets the limitr; < Tinay: Here, we conclude that to adjust the sending rate at the source, 
PACEC uses the following steps: 

a. The SDN controller calculates resources on a path at each period Tc. This resource calculation covers 
bandwidth availability which is then converted into path rate (Rp). 

b. Ingress switch receives information from the SDN controller for each period of controlling T.. Ingress 
switch passes this information to the source. 

c. The source adjusts its sending rate based on the information received from ingress switch. The source 
transmits the flow at the rater; , corresponding to the rate-sharing algorithm at the source. The r; cannot 
exceed Rp, as the upper limit. The source will stream the flow with the same rate until there is a change 
of information rate. If there are N flows then XY r; < Rp. 


3. RESULTS AND ANALYSIS 

In this section, we report the simulation results collected with our implementation of PACEC in the 
Mininet Simulator. We compared the simulation results of the proposed method with other congestion 
control mechanisms such as RCP. Here we compared PACEC with RCP due to the reason that PACEC is a 
rate based congestion control such as RCP. We also compare PACEC with TCP to see PACEC 
improvements overs important congestion control protocol on the Internet. To measure the performance of 
the congestion control mechanism, we evaluated the throughput, efficiency, smoothness, and fairness. As a 
reference scenario, we write the simulation parameters in Table 1. 


Table 1. Parameters of Simulation 


parameter value 
Bottleneck Link C=100 Mbps 
Buffer Size B [10,100] 
Simulation Time 100 seconds 
Emulator Mininet 
Controller Ryu 
Topology Abilene 
Packet Size 1500 Bytes 
RTT 50 ms 
Operating system Ubuntu 
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3.1. Throughput 

Figure 4 shows comparison throughput achievement of congestion control scheme. Our simulation 
is conducted by entering two kinds of flows consisting of large flow (flow A) and small flow (flow B) to the 
network. We measure the throughput for both flows. The simulation resulted in the average of throughput for 
PACEC is 48.9 Mbps, RCP is 46.3 Mbps, and TCP is 31, 45 Mbps for flow A. The simulation results for 
flow B obtained the average of throughput; PACEC is 12.27 Mbps, RCP is 11.58 Mbps, and TCP is 7.87 
Mbps. In this case, PACEC outperformed RCP and TCP. PACEC increased mean throughput achievement 
over RCP by 5.7% and TCP by 55.7%. 


60 
~ 50 
F 
2 40 == PA CEC (flow A) 
3 30 =H=RCP (flow A) 
5 =ġ=TCP (flow A) 
è ” == PACEC (flow B) 
£ 10 =>=RCP (flow B) 

=@=TCP (flow B) 


Time (s) 


Figure 4. Throughput achievement of congestion control scheme 


3.2. Efficiency 
The efficiency of the congestion control mechanism can be determined through the power 
parameters, i.e., the ratio between throughput and delay [24]. 


throughput 


power = (10) 


delay 


We summarize the simulation results in Table 2. We can see that PACEC has the highest power value 
compared to RCP and TCP. That indicated that PACEC is more efficient than RCP and TCP. 


Table 2. Efficiency comparison of PACEC, RCP, and TCP 


Congestion control scheme Throughput (Mbps) Delay (ms) Power (a=1) 
FlowA FlowB  FlowA  FlowB  FlowA _ FlowB 
PACEC 48,9 12,2 54,2 12,9 0,9 0,9 
RCP 46,3 11,5 57,1 14,6 0,8 0,8 
TCP 12,2 7,8 84,1 17,1 0,4 0,5, 


3.3. Smoothness 
Smoothness is an essential feature of congestion control. Here we declared smoothness as the ratio 
of the rate change between two successive update periods to the previous rate and written as [25] 


Xp, Xe 
Thm; = lxi = xi- (11) 
Xi-1 


where x; is the average throughput during the i-th interval for the flow (each range is Te sec). A flow 
smoothness index is defined as the mean throughput-change over its lifetime ratio, where T is the total time 
interval during the simulation. Smaller smoothness indices show smoother throughput changes [26]. 
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N 
Th, = ee) (12) 


We do a simulation of 10 different flows, a small flow having sizes (1-10 Kbps), medium (10Kbps- 
1Mbps), and large (1-100Mbps) within 100 seconds. We declare the throughput fluctuation with the 
smoothness parameter as in (12). Table 3 shows the comparison of smoothness index for each flow. The 
smoothness index captures the time series of rate changes. A smaller smoothness index indicates smoother 
throughput change for a flow. 


Table 3. Comparison of Smoothness (Th) 
Flowid Flow type PACEC RCP TCP 


1 small 0,05 0,09 0,13 

2 medium 0,03 0,04 0,10 
3 medium 0,02 0,09 0,17 

4 medium 0,02 0,09 0,16 
5 medium 0,02 0,03 0,06 
6 large 0,02 0,08 0,06 
7 large 0,03 0,04 0,10 
8 large 0,02 0,08 0,11 
9 large 0,02 0,07 0,12 
10 large 0,02 0,06 0,18 
average 0,025 0,067 0,12 


The simulation results show that smoothness index for PACEC varies from 0.02 to 0.05, it varies 
from 0.03 to 0.09 for RCP, and varies from 0.06 to 0.18 for TCP. Based on these values, indicating that 
PACEC is smoother compared with RCP and TCP. 


3.4. Fairness 
Fairness is used to decide whether the user or application receives a fair share of system resources. 
Here, we use the mathematical definition from Jain and Chiu [26]. Fairness can be written as 


Èi x)? 


n.p x? 


e Xa) ee Xp) = (13) 


where xi is the throughput of flow i and n is the sum of flow. We consider the medium-term fairness of 
PACEC. To evaluate medium-term fairness, we obtain the average throughput of PACEC flows over the 
entire time of simulation (100 seconds). We simulated 20 identical flows (10 Mbps). Based on equation (13), 
we got fairness index for 20 identical flows as shown in Figure 5. The fairness index of PACEC is smaller 
than RCP and RCP. The fairness index of PACEC is 0.99 (close to one) which indicates that the throughput 
assignment for a competing flow in PACEC is fair. 


0,99 
0,98 | 0,97 
0,96 | 
0,94 + 
Í 0,9 
09 4 
0,88 + 
0,86 + 
0,84 + - r 
RCP TCP 


PACEC 


Fairness index 
° 
wo 
N 


Figure 5. Fairness index of congestion control scheme 
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4. CONCLUSION 

In this paper, we designed a new Router Assisted Congestion Control (RACC) mechanism that 
works with the SDN framework. This mechanism is designed to overcome weaknesses in traditional Internet 
networks that cannot provide global information networks. We propose a scheme that uses explicit 
information from the controller as a network policy determiner. Based on the information from the controller, 
the sender can adjust the sender rate according to the network conditions. The sender does not need to adjust 
the sending rate incrementally. We have demonstrated through computer simulation that the scheme is able to 
use the network bandwidth more efficiently and more consistently, and also able to maintain fairness of any 
flow that requests network services. For future works, we plan to integrate this scheme with admission 
control and bandwidth allocation mechanism. 
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